Skip to content

UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification - #962

Open
Jianping (Jianping-Li) wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
Jianping-Li:drop_notice
Open

UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification#962
Jianping (Jianping-Li) wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
Jianping-Li:drop_notice

Conversation

@Jianping-Li

@Jianping-Li Jianping (Jianping-Li) commented Aug 17, 2026

Copy link
Copy Markdown

Newer DSP firmware implements a PD (Protection Domain) notification framework that sends PD state notifications upon request. The PD exit notification is unconditionally sent by the DSP with a fixed sentinel 0xABCDABCD in the context field.

fastrpc_rpmsg_callback() treats every inbound message as an invoke response, so the sentinel is masked and shifted like any real response ((0xABCDABCD & 0xFF0) >> 4 == 188) and looked up in the channel's context idr.

This is not merely cosmetic. In the common case idr slot 188 is empty, the lookup fails, and the driver only logs a spurious "No context ID matches response" error on every teardown. But the context idr is shared by every protection domain and the listener thread on the channel and is filled cyclically over [1, FASTRPC_CTX_MAX]. If slot 188 holds a live context when the sentinel arrives, the sentinel's return value is written into that unrelated in-flight invocation and it is completed early.

Since neither the fastrpc library nor the driver supports the DSP PD notification framework, it is safe to drop the PD exit notification before it is ever turned into a context lookup. This removes both the log spam and the mis-completion race. A genuine response can never be masked: a real context is (idr_index << 4) | pd (at most 0xFF3) and can never equal the sentinel.

Link: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5
CRs-Fixed: 4633198

@qlijarvis

qlijarvis commented Aug 17, 2026

Copy link
Copy Markdown

PR #962 — validate-patch

PR: #962

Verdict Issues Detailed Report
❌ 0 Full report

Final Summary

  1. Lore link present: No — PR links to git.kernel.org commit in linux-next (5533bb4), not lore.kernel.org. However, the upstream commit message contains a lore link: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org

  2. Lore link matches PR commits: N/A — PR does not link to lore; it links directly to the git commit. The diff content is functionally identical to upstream, with only context line number differences due to applying to an older base tree.

  3. Upstream patch status: ✅ ACKed — merged into linux-next as commit 5533bb4bc53c with sign-offs from Srinivas Kandagatla (maintainer) and Greg Kroah-Hartman (char-misc subsystem maintainer). Commit dated 2026-07-29, likely queued for mainline in the next merge window.

  4. PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #962 - UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Upstream commit: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream ✅ Subject identical (UPSTREAM: prefix added correctly)
Body preserves rationale ✅ Full commit message body preserved verbatim
Fixes tag present/correct N/A No Fixes tag in upstream (new feature/fix, not regression fix)
Authorship preserved ❌ CRITICAL: PR author is Jianping Li <jianping.li@oss.qualcomm.com> but upstream author is Shawn Guo <shengchao.guo@oss.qualcomm.com>. For UPSTREAM: commits, the From: field must match the original author.
Backport note (if applicable) N/A Not a backport to stable; this is a forward-port from linux-next

Diff

File Status Notes
drivers/misc/fastrpc.c ⚠️ Code logic identical; context differs (PR applies to older tree without FASTRPC_CTXID_SEQ_* defines). This is acceptable for integration into an older base, but the line numbers differ: upstream adds at line 51, PR adds at line 48.

Issues

  1. Author mismatch (FAIL): The PR's From: field shows Jianping Li but the upstream commit author is Shawn Guo. For UPSTREAM: commits, the original author must be preserved. Fix with:

    git commit --amend --author="Shawn Guo <shengchao.guo@oss.qualcomm.com>"

  2. Missing upstream trailers (WARNING): The PR is missing the following trailers from the upstream commit:

    • Assisted-by: Claude:claude-opus-4-8
    • Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
    • Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> (original author)
    • Signed-off-by: Srinivas Kandagatla <srini@kernel.org> (maintainer)
    • Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (subsystem maintainer)

    At minimum, the original author's Signed-off-by must be present. The maintainer sign-offs can be omitted as they represent the upstream merge path, but the original author's SoB is mandatory.

  3. Context adaptation (ACCEPTABLE): The diff context differs because the PR applies to an older kernel tree that lacks the FASTRPC_CTXID_SEQ_SHIFT and FASTRPC_CTXID_SEQ_MASK defines present in linux-next. The code logic is identical and correctly adapted.

Verdict

Do not merge until the author field is corrected to Shawn Guo <shengchao.guo@oss.qualcomm.com> and the original author's Signed-off-by is added to the commit message. The current PR incorrectly attributes the patch to Jianping Li, which violates kernel authorship conventions for UPSTREAM: commits.

Final Summary

  1. Lore link present: No — PR links to git.kernel.org commit in linux-next (5533bb4), not lore.kernel.org. However, the upstream commit message contains a lore link: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org

  2. Lore link matches PR commits: N/A — PR does not link to lore; it links directly to the git commit. The diff content is functionally identical to upstream, with only context line number differences due to applying to an older base tree.

  3. Upstream patch status: ✅ ACKed — merged into linux-next as commit 5533bb4bc53c with sign-offs from Srinivas Kandagatla (maintainer) and Greg Kroah-Hartman (char-misc subsystem maintainer). Commit dated 2026-07-29, likely queued for mainline in the next merge window.

  4. PR present in qcom-next/topics: Yes — per integration_presence_report.md: "present - all checked added lines are present" in topics (topics/early/hwe/eliza, topics/early/hwe/nord-next)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 21f58ca3b79427e34eafb4c18ff916d8bb95f7ea
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 [PATCH] UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

Final Status

overall_status: PASS
present_commits: 1/1
partial_commits: 0/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

@qlijarvis

qlijarvis commented Aug 17, 2026

Copy link
Copy Markdown

PR #962 — checker-log-analyzer

PR: #962
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/32020037254

Checker Result Summary
Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ No sparse warnings
check-uapi-headers ✅ No UAPI changes
check-patch-compliance ❌ Invalid Link URL format
tag-check ✅ Subject has valid UPSTREAM: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #962 - UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32020037254
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ No sparse warnings
check-uapi-headers ✅ No UAPI changes
check-patch-compliance ❌ Invalid Link URL format
tag-check ✅ Subject has valid UPSTREAM: prefix

❌ check-patch-compliance

Root cause: The Link: trailer points to a git.kernel.org cgit web URL instead of a lore.kernel.org mbox URL, which b4 am cannot fetch.

Failure details:

Checking commit: UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5

The commit message contains:

Link: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5

This is a cgit web interface URL. The check-patch-compliance checker uses b4 am to fetch and compare patches, which requires a lore.kernel.org URL (e.g., https://lore.kernel.org/...) or a message-ID.

Fix: Replace the git.kernel.org cgit URL with the corresponding lore.kernel.org URL for the patch submission.

  1. Search for the patch on lore.kernel.org using the commit ID or subject:

    # Search by commit ID
lei q -o /tmp/search "id:5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5"
# OR search by subject
lei q -o /tmp/search "s:misc fastrpc Drop unhandled DSP PD exit notification"

  2. Once you find the lore URL (it will look like https://lore.kernel.org/linux-arm-msm/<message-id>/), update the commit:

    git rebase -i bfeb0e5567c0   # base of qcom-6.18.y
# mark the commit as 'edit'
git commit --amend
# In the editor, replace the Link: line with the lore.kernel.org URL
git rebase --continue

  3. If the patch was never posted to a mailing list (only merged directly to linux-next), you have two options:

    • Option A (preferred): Find the original mailing list submission that led to the linux-next merge and use that lore URL
    • Option B: Use the mainline commit URL format: Link: https://git.kernel.org/linus/5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5 (if merged to mainline)

Reproduce locally:

# This will fail with the current cgit URL:
b4 am --single-message -C -l -3 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5

# After fixing to a lore URL, it should succeed:
b4 am --single-message -C -l -3 https://lore.kernel.org/linux-arm-msm/<message-id>/

Verdict

1 blocker to fix before merge: The Link: trailer must point to a lore.kernel.org URL (or a valid mainline commit URL format) instead of the cgit web interface URL. All other checkers passed or were correctly skipped.

@Jianping-Li
UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
69e097d 
Newer DSP firmware implements a PD (Protection Domain) notification
framework that sends PD state notifications upon request. The PD exit
notification is unconditionally sent by the DSP with a fixed sentinel
0xABCDABCD in the context field.

fastrpc_rpmsg_callback() treats every inbound message as an invoke
response, so the sentinel is masked and shifted like any real response
((0xABCDABCD & 0xFF0) >> 4 == 188) and looked up in the channel's
context idr.

This is not merely cosmetic. In the common case idr slot 188 is empty,
the lookup fails, and the driver only logs a spurious "No context ID
matches response" error on every teardown. But the context idr is shared
by every protection domain and the listener thread on the channel and is
filled cyclically over [1, FASTRPC_CTX_MAX]. If slot 188 holds a live
context when the sentinel arrives, the sentinel's return value is written
into that unrelated in-flight invocation and it is completed early.

Since neither the fastrpc library nor the driver supports the DSP PD
notification framework, it is safe to drop the PD exit notification
before it is ever turned into a context lookup. This removes both the
log spam and the mis-completion race. A genuine response can never be
masked: a real context is (idr_index << 4) | pd (at most 0xFF3) and
can never equal the sentinel.

Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
@qcomlnxci

qcomlnxci commented Aug 18, 2026

Copy link
Copy Markdown

Test jobs on 69e097d

@qcomlnxci

qcomlnxci commented Aug 18, 2026

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ◻️
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Ethernet ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ◻️
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ✅ Pass ◻️
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ✅ Pass ◻️
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ✅ Pass ◻️
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ◻️
WiFi_Firmware_Driver ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
WiFi_OnOff ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ◻️
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️

@qlijarvis

qlijarvis commented Aug 21, 2026

Copy link
Copy Markdown

PR #962 — validate-patch

PR: #962

Verdict Issues Detailed Report
❌ 4 Full report

Final Summary

  1. Lore link present: Yes — https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org (equivalent to lore.kernel.org)
  2. Lore link matches PR commits: Yes — diff content is identical; line number shifts are due to different base tree context
  3. Upstream patch status: ✅ Upstreamed — merged as 5533bb4bc53c in topics/early/hwe/eliza and topics/early/hwe/nord-next (not yet in qcom-next)
  4. PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #962 - UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Upstream commit: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org (merged as 5533bb4bc53c in topics/early/hwe/eliza, topics/early/hwe/nord-next)
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream ✅ Subject identical except for UPSTREAM: prefix
Body preserves rationale ✅ Full commit message preserved verbatim
Fixes tag present/correct N/A No Fixes tag in upstream or PR
Authorship preserved ❌ FAIL: From: is Jianping Li but upstream author is Shawn Guo
Backport note (if applicable) N/A Not a backport; commit is from topics branch

Diff

File Status Notes
drivers/misc/fastrpc.c ✅ Code changes identical; context differs due to different base tree (line numbers shifted)

Issues

Critical: Authorship Mismatch

The PR commit has:

From: Jianping Li <jianping.li@oss.qualcomm.com>

But the upstream commit 5533bb4bc53c has:

Author: Shawn Guo <shengchao.guo@oss.qualcomm.com>

For UPSTREAM: commits, the original author must be preserved in the From:/Author: field. The person who cherry-picks the commit should only add their Signed-off-by: trailer, not replace the author.

Fix required:

git commit --amend --author="Shawn Guo <shengchao.guo@oss.qualcomm.com>"

The commit message already has the correct sign-off chain:

  • Signed-off-by: Shawn Guo (original author) ✅
  • Signed-off-by: Srinivas Kandagatla (subsystem maintainer) ✅
  • Signed-off-by: Greg Kroah-Hartman (char-misc maintainer) ✅
  • Signed-off-by: Jianping Li (person applying to this tree) ✅

Only the From: field needs correction.

Verdict

Do not merge until authorship is corrected. The diff content is faithful to upstream (context-only differences are expected when applying to a different base), but the From: field violates the UPSTREAM: commit authorship requirement.

Final Summary

  1. Lore link present: Yes — https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org (equivalent to lore.kernel.org)
  2. Lore link matches PR commits: Yes — diff content is identical; line number shifts are due to different base tree context
  3. Upstream patch status: ✅ Upstreamed — merged as 5533bb4bc53c in topics/early/hwe/eliza and topics/early/hwe/nord-next (not yet in qcom-next)
  4. PR present in qcom-next/topics: Yes — integration_presence_report.md confirms present in topics (1/1 commits)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 [PATCH] UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

Final Status

overall_status: PASS
present_commits: 1/1
partial_commits: 0/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

@qlijarvis

qlijarvis commented Aug 21, 2026

Copy link
Copy Markdown

PR #962 — checker-log-analyzer

PR: #962
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/32116565333

Checker Result Summary
Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ No static analysis warnings
check-uapi-headers ✅ No UAPI ABI changes
check-patch-compliance ❌ Author mismatch
tag-check ✅ Subject prefix UPSTREAM: present

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #962 — UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32116565333
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ No static analysis warnings
check-uapi-headers ✅ No UAPI ABI changes
check-patch-compliance ❌ Author mismatch
tag-check ✅ Subject prefix UPSTREAM: present

❌ check-patch-compliance

Root cause: The commit author in the PR (Jianping Li <jianping.li@oss.qualcomm.com>) does not match the original upstream author (Shawn Guo <shengchao.guo@oss.qualcomm.com>).

Failure details:

Checking commit: UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification
Author mismatch:
  Original author: Shawn Guo <shengchao.guo@oss.qualcomm.com>
  Commit author : Jianping Li <jianping.li@oss.qualcomm.com>

The commit message correctly attributes the original author via Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>, but the Git Author: field must match the upstream author for UPSTREAM: commits.

Fix:

git rebase -i c57b63497cd7   # mark commit 69e097d467af as 'edit'
git commit --amend --author="Shawn Guo <shengchao.guo@oss.qualcomm.com>"
git rebase --continue

Keep the Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> trailer to indicate who backported the patch.

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base c57b63497cd72a45c8992e05373f7b32901cf029 \
  --head 69e097d467afaf2346149f55bbfb16849462fbc5

Verdict

Fix 1 blocker before merge: The Git Author: field must be corrected to match the upstream author Shawn Guo <shengchao.guo@oss.qualcomm.com>. All other checkers passed cleanly.

@qlijarvis

qlijarvis commented Aug 21, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #962

Job 207586 | SoC lemans-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207586

Failed test cases in LAVA job 207586 (SoC: lemans-evk).

  Case 1: Probe_Failure_Check — Test Infrastructure False Positive
  1. Failed case: Probe_Failure_Check — Test Infrastructure False Positive
  2. Root cause: Test flagged deferred probe warnings and benign firmware load failures as errors. The 4 PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state but do not block boot or cause functional failures. Bluetooth firmware load failures (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) are suppressed per lava-known-benign-failures.md Rule 3 because BT_ON_OFF test passed, confirming Bluetooth is functional. Regulatory.db failure is from faux_driver (test/dummy driver) with no functional impact.
  3. Possible fix: Update Probe_Failure_Check test logic to (1) exclude deferred probe warnings that do not block boot completion, (2) apply lava-known-benign-failures.md suppression rules for firmware load failures when corresponding functional tests pass, and (3) filter out faux_driver/test driver errors. This is not a kernel regression — the PR (fastrpc DSP PD notification fix) does not touch PMIC thermal, Bluetooth firmware loading, or regulatory subsystems.
  4. Detail analysis attachment: failed_case_job207586_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: The video codec device aa00000.video-codec is not attached to any IOMMU group because it does not exist or failed to probe on the lemans-evk platform; this is a pre-existing platform configuration issue unrelated to the PR's fastrpc driver changes.
  3. Possible fix: Update the lemans-evk device tree to include and enable the video codec device node at address 0xaa00000, or update the smmu test's critical device list to exclude aa00000.video-codec for lemans-evk if this device is not present on this platform.
  4. Detail analysis attachment: failed_case_job207586_2_detailed.md
  Case 3: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test runner marked the test definition as failed due to "Marking unfinished test run as failed" after completing all individual test cases. The test runner printed result file list and exited with <LAVA_TEST_RUNNER EXIT>, but LAVA dispatcher interpreted this as an incomplete test run. Two individual test failures occurred: (1) Probe_Failure_Check failed due to deferred probe devices (temp-alarm@a00 on 4 PMICs) and missing firmware files (regulatory.db, Bluetooth firmware), and (2) smmu test failed because video codec device aa00000.video-codec is not attached to an IOMMU group. These failures are pre-existing infrastructure/configuration issues unrelated to the PR's fastrpc driver change.
  3. Possible fix: The overall test definition failure is a false positive caused by LAVA test runner behavior. The two genuine test failures are pre-existing: (1) For Probe_Failure_Check: add missing firmware files to the rootfs or suppress these known benign firmware load failures in the test; add thermal driver support for the PMIC temp-alarm devices or mark them as expected deferred probes. (2) For smmu: configure the video codec device tree node to attach aa00000.video-codec to an IOMMU group, or update the smmu test to exclude video codec from critical master checks on lemans-evk. Neither failure is caused by the PR's fastrpc PD notification sentinel fix.
  4. Detail analysis attachment: failed_case_job207586_3_detailed.md
Job 207587 | SoC qcs9100-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207587

Failed test cases in LAVA job 207587 (SoC: qcs9100-ride).

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test detected two hard probe failures (regulatory.db firmware missing, Aquantia PHY DT property missing) and four deferred probe conditions (PMIC temp-alarm devices missing IIO ADC dependency) — all pre-existing platform/configuration issues unrelated to the fastrpc PR changes.
  3. Possible fix: These are pre-existing platform configuration issues, not regressions introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962. To resolve: (1) Add regulatory.db to rootfs firmware directory, (2) Add firmware-name property to Aquantia PHY DT node at stmmac-0:08, (3) Enable and configure qcom-spmi-adc5 driver or verify thermal zone provider for PMIC temp-alarm devices. However, since WiFi, Bluetooth, and core system functionality are confirmed working (all functional tests passed), these failures can be treated as non-blocking for this PR.
  4. Detail analysis attachment: failed_case_job207587_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Video codec device (aa00000.video-codec) on qcs9100-ride is missing IOMMU group attachment in device tree — the device exists but lacks the required iommus property binding it to an SMMU context bank. This is a pre-existing platform/DT configuration issue, not a runtime SMMU fault or a regression introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies drivers/misc/fastrpc.c).
  3. Possible fix: Add the missing iommus property to the video-codec@aa00000 node in arch/arm64/boot/dts/qcom/qcs9100.dtsi, referencing the appropriate APPS_SMMU context bank. Example: iommus = <&apps_smmu 0x21c0 0x0>; (verify correct SID from hardware documentation). After applying the fix, rebuild the DTB and verify the device appears in /sys/kernel/iommu_groups/*/devices/.
  4. Detail analysis attachment: failed_case_job207587_2_detailed.md
  Case 3: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)
  1. Failed case: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)
  2. Root cause: ** The USBHost test expects physical USB devices (keyboard, mouse, storage, etc.) to be connected to the qcs9100-ride board's USB ports, but the LAVA lab hardware setup has no USB peripherals attached. The USB host controller subsystem is functioning correctly — xhci-hcd drivers loaded successfully, three USB buses (Bus 001 USB 2.0, Bus 002 USB 3.0, Bus 003 USB 2.0) are operational, and USB root hubs are detected. The test enumerates USB devices using lsusb and finds only the three Linux Foundation root hubs (ID 1d6b:0002 and 1d6b:0003), then explicitly fails with "Only USB hubs detected, no functional USB devices." This is a test hardware availability issue specific to the qcs9100-ride LAVA lab setup, not a kernel defect or regression introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962.
  3. Possible fix: Update the LAVA job definition for qcs9100-ride to mark the USBHost test as "skip" with reason "USB test peripherals not available in lab setup" until USB devices (flash drive, keyboard, or hub with peripherals) are physically connected to the board's USB ports. Alternatively, connect at least one USB test device to the board and verify it enumerates correctly, then re-enable the test. This is not a kernel bug and requires no code changes.
  4. Detail analysis attachment: failed_case_job207587_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test runner infrastructure failure — the test runner script (result_parse.sh) completed and sent <LAVA_TEST_RUNNER EXIT> without emitting the required LAVA_SIGNAL_ENDRUN signal, causing LAVA dispatcher to mark the test run as unfinished.
  3. Possible fix: This is a LAVA test infrastructure bug, not a kernel regression. The test runner script at /lava-207587/0/tests/0_qcom-next-ci-premerge-tests/Runner/utils/result_parse.sh must be fixed to emit printf "<LAVA_SIGNAL_ENDRUN %s %s>\\n" "$TESTRUN_ID" "$UUID" before exiting. Re-trigger the CI job after fixing the test runner script.
  4. Detail analysis attachment: failed_case_job207587_4_detailed.md
Job 207588 | SoC qcs615-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207588

Failed test cases in LAVA job 207588 (SoC: qcs615-ride).

  Case 1: Probe_Failure_Check — Firmware Load Failure (Non-Genuine)
  1. Failed case: Probe_Failure_Check — Firmware Load Failure (Non-Genuine)
  2. Root cause: The regulatory.db firmware file is missing from the qcs615-ride rootfs at /lib/firmware/regulatory.db. The cfg80211 wireless regulatory subsystem attempts to load this file during boot but gracefully falls back to built-in regulatory rules when the file is absent. This is a pre-existing rootfs packaging issue, not a kernel regression. The PR patch (fastrpc DSP notification handling) does not touch firmware loading, cfg80211, or wireless subsystems.
  3. Possible fix: This is a false positive test failure. The Probe_Failure_Check test should suppress firmware load failures for regulatory.db when WiFi/BT functional tests pass. No kernel fix is required. To eliminate the test failure, add the wireless-regdb package (containing regulatory.db) to the qcs615-ride rootfs build recipe.
  4. Detail analysis attachment: failed_case_job207588_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: The SMMU test expects video codec child devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be independently attached to IOMMU groups, but on qcs615-ride these are V4L2 video device nodes created by the qcom-venus driver, not platform devices with separate DT nodes, so they do not appear in /sys/kernel/iommu_groups/*/devices/.
  3. Possible fix: Update the SMMU test script to recognize that for qcom-venus video codec on qcs615, the parent platform device (aa00000.video-codec) IOMMU group attachment is sufficient; child V4L2 video nodes inherit IOMMU protection through the parent device and do not require separate iommu_group sysfs entries.
  4. Detail analysis attachment: failed_case_job207588_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM cannot initialize because the kernel is running as a guest under the Gunyah hypervisor (EL1) rather than at EL2 (hypervisor mode). The kernel message "kvm [1]: HYP mode not available" at boot confirms that KVM detected it does not have access to EL2, which is required to create the /dev/kvm device node.
  3. Possible fix: This is not a kernel regression introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies fastrpc driver). This is a platform configuration issue specific to qcs615-ride running under Gunyah hypervisor. To enable KVM testing on this platform, either: (1) boot the kernel directly at EL2 without Gunyah, or (2) use nested virtualization if Gunyah supports it, or (3) exclude KVM tests from the qcs615-ride LAVA job definition since this platform is configured for Gunyah-based virtualization, not KVM.
  4. Detail analysis attachment: failed_case_job207588_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel software bug. If KVM support is required on QCS615 Ride: (1) Verify the SoC datasheet confirms ARM Virtualization Extensions support; (2) Check bootloader (ABL/XBL) configuration to ensure it enters the kernel at EL2; (3) Verify TrustZone/firmware does not disable EL2. If the platform fundamentally lacks EL2 support, mark KVM tests as "not applicable" for this board in the LAVA test suite configuration.
  4. Detail analysis attachment: failed_case_job207588_4_detailed.md
  Case 5: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** The qcs615-ride hardware does not support ARM Virtualization Extensions (EL2/HYP mode). KVM driver initialization fails at boot with kvm [1]: HYP mode not available because the CPU is not running in or cannot enter EL2 (Hypervisor mode), which is a mandatory hardware requirement for KVM on ARM64.
  3. Possible fix: This is a hardware/platform limitation, not a kernel bug. Disable KVM tests for qcs615-ride in the LAVA test suite configuration, or mark them as expected-to-skip for platforms without virtualization support. The test framework should check for /dev/kvm presence before running KVM tests and skip gracefully.
  4. Detail analysis attachment: failed_case_job207588_5_detailed.md
  Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. To resolve: (1) Verify qcs615-ride hardware supports EL2; (2) Check if EL2 is disabled in the secure boot chain (TZ/ABL); (3) If EL2 is available, ensure the bootloader passes control to Linux at EL2; (4) If EL2 is not available on this platform, mark KVM tests as "not applicable" for qcs615-ride in the LAVA test suite configuration by adding skip rules for KVM_EL2_DTB and KVM_Infra tests on this platform.
  4. Detail analysis attachment: failed_case_job207588_6_detailed.md
Job 207589 | SoC hamoa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207589

Failed test cases in LAVA job 207589 (SoC: hamoa-evk).

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Three pre-existing driver probe failures unrelated to PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource conflict, (2) qcom-spmi-lpg fails with -EINVAL due to invalid "reg" property in multi-led device tree node for hamoa-evk PMIC, (3) regulatory.db firmware file missing from rootfs causing cfg80211 initialization warning.
  3. Possible fix: These are known platform-specific issues on hamoa-evk, not regressions introduced by the fastrpc patch. Suppress this test failure for PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 validation. For long-term fixes: (1) update TZ firmware or qseecom DT bindings for hamoa-evk, (2) correct the PMIC multi-led "reg" property in arch/arm64/boot/dts/qcom/x7181.dtsi or board DTS, (3) include wireless-regdb package in the rootfs image.
  4. Detail analysis attachment: failed_case_job207589_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test infrastructure bug — test incorrectly expects USB DT wrapper nodes (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and a non-existent video codec device (aa00000.video-codec) to have IOMMU group attachments; actual USB controllers (a000000, a200000, a400000, a600000, a800000) are correctly IOMMU-protected.
  3. Possible fix: Update the smmu test's device list for hamoa-evk to exclude USB wrapper nodes and the non-existent video codec device; only check actual DMA master devices (USB controllers at a000000, a200000, a400000, a600000, a800000).
  4. Detail analysis attachment: failed_case_job207589_2_detailed.md
  Case 3: ** WiFi_Firmware_Driver (Test Framework False Positive)
  1. Failed case: ** WiFi_Firmware_Driver (Test Framework False Positive)
  2. Root cause: ** Test script fails on recoverable driver warning "qmi dma allocation failed (7274496 B type 1), will try later with small size" without verifying that the ath12k_wifi7_pci driver successfully recovered, loaded firmware, and created the wlP4p1s0 interface. This is a test validation bug, not a kernel or driver regression.
  3. Possible fix: Update the WiFi test framework to distinguish between recoverable warnings and hard probe failures. The test should verify final probe outcome (interface creation, firmware load completion) rather than failing on intermediate retry messages. For hamoa-evk with ath12k_wifi7_pci, the test should pass if the interface is created and firmware version is reported, even if DMA allocation retries occurred.
  4. Detail analysis attachment: failed_case_job207589_3_detailed.md
  Case 4: WiFi_OnOff — WiFi driver probe warning (false positive)
  1. Failed case: WiFi_OnOff — WiFi driver probe warning (false positive)
  2. Root cause: The WiFi_OnOff test detected a transient "qmi dma allocation failed (7274496 B type 1), will try later with small size" warning message from the ath12k_wifi7_pci driver during probe at boot time (timestamp 13.754346). However, this is a non-fatal warning: the driver's built-in retry mechanism immediately recovered, successfully initialized the hardware (chip_id 0x2, fw_version 0x1103006c detected at 13.774992-13.785429), and created the WiFi interface (wlan0 renamed to wlP4p1s0 at 14.095168). The test harness incorrectly classified this transient warning as a probe failure despite successful driver initialization.
  3. Possible fix: Update the WiFi_OnOff test harness to distinguish between fatal probe failures and transient warnings that are followed by successful recovery. The test should verify final driver state (interface creation, firmware load completion) rather than flagging any warning message containing "failed" during the probe sequence. Alternatively, suppress this specific "qmi dma allocation failed...will try later" pattern when it is followed by successful chip_id/fw_version detection and interface creation within the same boot sequence.
  4. Detail analysis attachment: failed_case_job207589_4_detailed.md
  Case 5: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: No kernel fix required. This is a platform hardware/firmware limitation. To enable KVM on hamoa-evk: (1) Verify SoC specifications confirm EL2 support; (2) If EL2 is present but reserved by firmware, update bootloader/TrustZone configuration to make EL2 available to Linux; (3) If EL2 is not present in hardware, KVM cannot be enabled — exclude KVM tests from hamoa-evk CI validation or mark as expected skip.
  4. Detail analysis attachment: failed_case_job207589_5_detailed.md
  Case 6: ** KVM_EL2_DTB — KVM device node unavailable (test environment limitation)
  1. Failed case: ** KVM_EL2_DTB — KVM device node unavailable (test environment limitation)
  2. Root cause: ** The hamoa-evk board is running under Gunyah hypervisor which occupies EL2 (HYP mode), preventing KVM from initializing. KVM requires exclusive EL2 access and cannot function in a nested virtualization scenario. The kernel correctly reports "kvm [1]: HYP mode not available" during boot, and consequently /dev/kvm is never created.
  3. Possible fix: This is not a kernel bug. Either (1) disable KVM tests on hamoa-evk when running under Gunyah hypervisor, or (2) configure the test environment to boot hamoa-evk without a hypervisor if KVM testing is required. The PR patch (fastrpc driver fix) is unrelated and does not cause this failure.
  4. Detail analysis attachment: failed_case_job207589_6_detailed.md
  Case 7: KVM Infrastructure Unavailable — Gunyah Hypervisor Blocks EL2 Access
  1. Failed case: KVM Infrastructure Unavailable — Gunyah Hypervisor Blocks EL2 Access
  2. Root cause: The hamoa-evk platform boots under the Gunyah hypervisor (gunyah-mobile-c487961e9), which runs at EL2 and prevents the Linux kernel from accessing HYP mode. KVM requires EL2 access to create /dev/kvm, but the kernel detects "HYP mode not available" at boot (line 6.333423s) because Gunyah has already claimed EL2. This is a platform architecture constraint, not a kernel regression.
  3. Possible fix: This is expected behavior on Gunyah-based platforms where nested virtualization is not enabled. To enable KVM on hamoa-evk: (1) verify Gunyah firmware supports nested virtualization (VHE/nVHE passthrough to Linux), (2) if supported, enable nested KVM in Gunyah configuration and rebuild firmware, (3) if not supported, exclude KVM tests from the hamoa-evk CI test suite as they cannot pass on this platform architecture. The PR patch (fastrpc fix) is unrelated and did not cause this failure.
  4. Detail analysis attachment: failed_case_job207589_7_detailed.md
  Case 8: ** KVM_Infra (platform limitation — not a kernel regression)
  1. Failed case: ** KVM_Infra (platform limitation — not a kernel regression)
  2. Root cause: ** KVM cannot initialize on Hamoa IoT EVK because the platform boots Linux at EL1 without EL2 (Hypervisor mode) access. The kernel message kvm [1]: HYP mode not available confirms the CPU exception level does not support virtualization.
  3. Possible fix: This is not a kernel bug or PR-introduced regression. The Hamoa IoT EVK platform does not support KVM virtualization due to bootloader/firmware configuration. To enable KVM: (1) configure the bootloader to boot Linux at EL2, or (2) exclude KVM tests from the Hamoa test suite, or (3) use a different platform (e.g., RB5, RB3Gen2) that boots with EL2 enabled.
  4. Detail analysis attachment: failed_case_job207589_8_detailed.md
Job 207590 | SoC purwa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207590

Failed test cases in LAVA job 207590 (SoC: purwa-evk).

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Test detected five probe failures in dmesg (qcom_qseecom_uefisecapp -EBUSY, qcom-pcie 1bf8000/1bd0000 -ENODATA, qcom-spmi-lpg -EINVAL, regulatory.db -ENOENT). All five are pre-existing platform-specific issues on purwa-evk, NOT regressions introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies drivers/misc/fastrpc.c).
  3. Possible fix: Add a platform-specific suppression list to the Probe_Failure_Check test for purwa-evk to exclude known non-regression probe failures: qcom_qseecom_uefisecapp (UEFI secure app not exposed), qcom-pcie instances (not configured/connected), qcom-spmi-lpg (DT mismatch), and regulatory.db (missing from rootfs). Alternatively, enhance the test to be PR-aware by comparing against a baseline to detect only new probe failures.
  4. Detail analysis attachment: failed_case_job207590_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Pre-existing platform device tree configuration issue on purwa-evk — six USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec (aa00000.video-codec) are missing iommu-map or iommus properties in their device tree nodes, preventing IOMMU group attachment despite SMMU hardware being functional.
  3. Possible fix: Add missing iommus or iommu-map properties to the affected device nodes in arch/arm64/boot/dts/qcom/purwa.dtsi (or the appropriate SoC-level DTSI); this is a device tree fix, not a kernel driver fix, and is unrelated to the fastrpc patch in PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962.
  4. Detail analysis attachment: failed_case_job207590_2_detailed.md
  Case 3: WiFi_Firmware_Driver
  1. Failed case: WiFi_Firmware_Driver
  2. Root cause: Test false positive — the WiFi test harness flagged a transient DMA allocation retry warning ("qmi dma allocation failed (7274496 B type 1), will try later with small size") as a probe failure, but the ath12k_wifi7_pci driver successfully recovered, loaded firmware (fw_version 0x1103006c), and created the wlP4p1s0 interface. The warning is a normal part of the driver's fallback allocation strategy on the purwa-evk platform with limited contiguous DMA memory.
  3. Possible fix: Update the WiFi test harness probe-failure pattern to exclude this specific "will try later with small size" message, as it indicates a successful retry path rather than a fatal error. The driver's graceful degradation to smaller DMA buffers is expected behavior on memory-constrained platforms and should not trigger test failure.
  4. Detail analysis attachment: failed_case_job207590_3_detailed.md
  Case 4: WiFi_OnOff — Driver Probe Warning (False Positive)
  1. Failed case: WiFi_OnOff — Driver Probe Warning (False Positive)
  2. Root cause: The ath12k_wifi7_pci driver logs a transient QMI DMA allocation warning (qmi dma allocation failed (7274496 B type 1), will try later with small size) during probe on purwa-evk, but successfully recovers using a smaller allocation size and completes probe. The WiFi_OnOff test script incorrectly flags this as a probe failure because it pattern-matches any "failed" string in the kernel log during the probe window, without verifying whether the driver ultimately succeeded.
  3. Possible fix: Update the WiFi_OnOff test script's probe check logic to distinguish between fatal probe failures (driver never completes probe, no interface created) and transient warnings with successful recovery (interface created and operational). The test should verify interface presence (e.g., wlP4p1s0 exists) rather than solely pattern-matching log strings.
  4. Detail analysis attachment: failed_case_job207590_4_detailed.md
  Case 5: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Platform architecture limitation — purwa-evk boots with Gunyah Type-1 hypervisor at EL2, Linux runs as guest at EL1. KVM requires Linux at EL2 and cannot initialize when another hypervisor occupies EL2. Kernel correctly detected this and reported "HYP mode not available".
  3. Possible fix: Exclude KVM tests from purwa-evk CI test suite, as this platform does not support KVM by design. Alternatively, if KVM testing is required, configure the platform to boot Linux directly at EL2 without Gunyah (requires bootloader/firmware reconfiguration).
  4. Detail analysis attachment: failed_case_job207590_5_detailed.md
  Case 6: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM driver initialization failed because the Gunyah hypervisor running on purwa-evk does not support KVM/EL2 mode — kernel message "kvm [1]: HYP mode not available" indicates the hypervisor has already claimed EL2 and does not expose the KVM interface to the kernel.
  3. Possible fix: This is not a PR-introduced regression (the PR modifies only drivers/misc/fastrpc.c, unrelated to KVM). The purwa-evk platform runs Gunyah hypervisor which does not support nested virtualization or KVM passthrough. To resolve: (1) disable KVM tests for purwa-evk in the LAVA test suite, or (2) if KVM support is required, configure the platform to boot without Gunyah or use a hypervisor that supports KVM passthrough.
  4. Detail analysis attachment: failed_case_job207590_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM cannot initialize on purwa-evk because the platform runs Linux as a guest VM under the Gunyah hypervisor, which occupies EL2 (HYP mode). KVM requires direct EL2 access for nested virtualization, but the kernel runs at EL1 and detects "HYP mode not available" during initialization.
  3. Possible fix: This is a platform architecture limitation, not a bug. Either: (1) Disable KVM tests for purwa-evk in the CI test suite since this platform is configured to run under Gunyah and cannot support KVM, or (2) If KVM support is required, reconfigure the platform to boot Linux directly at EL2 without the Gunyah hypervisor (requires firmware/boot configuration changes).
  4. Detail analysis attachment: failed_case_job207590_7_detailed.md
  Case 8: KVM_Driver, KVM_EL2_DTB, KVM_Infra (all three KVM test cases)
  1. Failed case: KVM_Driver, KVM_EL2_DTB, KVM_Infra (all three KVM test cases)
  2. Root cause: KVM hypervisor mode (EL2) is not available on the Purwa IoT EVK platform — kernel message kvm [1]: HYP mode not available indicates the CPU is not running in EL2 or the hypervisor is disabled, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
  3. Possible fix: This is a platform limitation, not a PR-introduced regression. The Purwa IoT EVK either lacks EL2 support in firmware/bootloader configuration or the hypervisor is explicitly disabled. To enable KVM: (1) verify the SoC supports virtualization extensions (ARMv8.0-A with VHE or ARMv8.1-A+), (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 instead of EL1, (3) confirm no hypervisor is already running that would prevent KVM from initializing. If the platform does not support EL2, mark these tests as "not applicable" for this board in the CI test matrix.
  4. Detail analysis attachment: failed_case_job207590_8_detailed.md
Job 207591 | SoC shikra-iqs-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207591

Failed test cases in LAVA job 207591 (SoC: shikra-iqs-evk).

  Case 1: GIC
  1. Failed case: GIC
  2. Root cause: Test script bug — the GIC test script assumes 8 CPUs and attempts to parse timer interrupt counts for CPUs 4-7, but shikra-iqs-evk has only 4 CPUs (0-3). When the script tries to extract columns 5-8 from /proc/interrupts line 12, it reads the descriptor fields ("GICv3", "Level", "arch_timer") instead of numeric interrupt counts, causing bash integer comparison errors at line 75.
  3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an 8-CPU assumption. The script should iterate only over CPUs that actually exist on the target platform.
  4. Detail analysis attachment: failed_case_job207591_1_detailed.md
  Case 2: Remoteproc Boot Failure — modem subsystem not auto-booted
  1. Failed case: Remoteproc Boot Failure — modem subsystem not auto-booted
  2. Root cause: remoteproc0 (modem/CQS) remains in "offline" state because it is not configured for automatic boot in the device tree or platform configuration for Shikra IQS EVK; remoteproc1 (cdsp) and remoteproc2 (lpaicp) auto-boot successfully, indicating the remoteproc framework is functional but modem lacks the auto-boot property or userspace trigger.
  3. Possible fix: Add the "qcom,auto-boot" property to the modem remoteproc device tree node for Shikra IQS EVK, or configure userspace to explicitly start the modem subsystem via "echo start > /sys/class/remoteproc/remoteproc0/state" if manual boot is the intended platform policy; verify the fix by confirming remoteproc0 reaches "running" state after boot.
  4. Detail analysis attachment: failed_case_job207591_2_detailed.md
  Case 3: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)
  1. Failed case: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)
  2. Root cause: The Probe_Failure_Check test detected six pre-existing platform configuration issues on shikra-iqs-evk: (1) audio codec a078000.codec missing mclk clock, (2) WiFi c800000.wifi missing vdd-1.8-xo regulator supply, (3) I2C device 3-0010 deferred with no reason string, (4) sound card snd-sc8280xp CPU DAI name resolution failure, (5) regulatory.db firmware file absent (benign — cfg80211 regulatory database is optional), and (6) cpufreq-dt probe failed with -EEXIST (error -17, indicating another cpufreq driver already registered). None of these failures are caused by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962, which only modifies the fastrpc driver to drop DSP PD exit notifications and does not touch audio, WiFi, regulators, firmware loading, or cpufreq subsystems.
  3. Possible fix: Mark this test case as a false positive for PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962. The probe failures are board/platform DT configuration issues that existed before this PR and are unrelated to the fastrpc changes. To resolve the underlying issues: (1) add the missing mclk clock reference to the va_macro codec DT node, (2) add the vdd-1.8-xo-supply property to the WiFi DT node, (3) investigate the I2C device 3-0010 binding and add the missing dependency, (4) fix the sound card DT cpu phandle for the Analog Playback DAI link, (5) optionally package regulatory.db in the rootfs (or suppress this benign warning in the test), and (6) investigate why two cpufreq drivers are attempting to register (likely a DT or kernel config issue where both qcom-cpufreq-hw and cpufreq-dt are enabled for the same platform).
  4. Detail analysis attachment: failed_case_job207591_3_detailed.md
  Case 4: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** Test infrastructure issue — no USB devices physically connected to the shikra-iqs-evk board's USB host port during test execution. The kernel USB subsystem is functioning correctly (USB core drivers loaded successfully), but the test expects at least one USB device to be enumerated and finds none.
  3. Possible fix: Connect a USB device (e.g., USB flash drive, keyboard, or hub) to the USB host port on the shikra-iqs-evk board before running the USBHost test. If this is a CI/LAVA infrastructure issue, update the test setup documentation to ensure USB devices are connected, or mark this test as SKIP for boards without permanently attached USB devices.
  4. Detail analysis attachment: failed_case_job207591_4_detailed.md
  Case 5: BT_SCAN (Test Environment Issue — No Discoverable Devices)
  1. Failed case: BT_SCAN (Test Environment Issue — No Discoverable Devices)
  2. Root cause: Bluetooth scanning functionality is working correctly (discovery starts/stops successfully, hci0 operational), but no nearby Bluetooth devices are present in the LAVA lab environment to be discovered during the 3×15s scan attempts.
  3. Possible fix: This is not a kernel bug. The test failure is environmental. To resolve: (1) Ensure at least one Bluetooth device (phone, beacon, or dedicated test device) is powered on, discoverable, and within RF range of the shikra-iqs-evk board in the LAVA lab during test execution, OR (2) Mark BT_SCAN as a conditional test that skips gracefully when no devices are present (test-environment-dependent), OR (3) Re-run the test when a Bluetooth device is confirmed present in the lab.
  4. Detail analysis attachment: failed_case_job207591_5_detailed.md
  Case 6: Kernel Crash — synchronous external abort in qcom_rng driver
  1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
  2. Root cause: The qcom_rng driver crashed with a synchronous external abort (0x96000010) at PC qcom_rng_read+0xc4 while the qcom_hwrng test was reading from /dev/hwrng. The abort indicates the driver attempted to access MMIO registers of the hardware RNG block but the access faulted, likely because the RNG hardware was not properly powered/clocked or the MMIO mapping is invalid. This is a pre-existing platform/driver issue on shikra-iqs-evk, not introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which modifies only drivers/misc/fastrpc.c).
  3. Possible fix: Investigate the qcom_rng driver probe and runtime PM state on shikra-iqs-evk. Verify that: (1) the RNG device node in DT has correct reg/clocks/power-domains properties, (2) clocks and power domains are enabled before MMIO access in qcom_rng_read, (3) runtime PM is correctly implemented. Check ClockDumps.txt and genpd_summary.txt from a ramdump to confirm RNG block power/clock state at crash time. As a short-term CI mitigation, skip the qcom_hwrng test on shikra-iqs-evk until the driver/DT issue is root-caused and fixed.
  4. Detail analysis attachment: failed_case_job207591_6_detailed.md
  Case 7: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)
  1. Failed case: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)
  2. Root cause: ** The qcom_rng driver attempted to read from a hardware RNG MMIO register during the qcom_hwrng test, but the hardware did not respond, causing a synchronous external abort (ESR 0x96000010). This is a hardware/firmware/platform initialization issue on the shikra-iqs-evk board. The system correctly entered ramdump/EDL mode, but LAVA timed out waiting for recovery. This failure is not related to PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (fastrpc patch).
  3. Possible fix: Skip the qcom_hwrng test on shikra-iqs-evk in the LAVA job definition until the hardware/firmware issue is resolved. Investigate the shikra device tree (verify clocks, MMIO base address) and firmware (verify RNG initialization in XBL/TZ). If the issue is board-specific, replace the board. If platform-wide, fix the device tree or firmware to correctly initialize the RNG hardware before kernel access.
  4. Detail analysis attachment: failed_case_job207591_7_detailed.md
  Case 8: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xc4 when the qcom_rng driver attempted to read from the hardware RNG MMIO registers. The faulting instruction b940035c (ldr w28, [x26]) attempted to dereference a mapped MMIO address that the hardware rejected with an external abort, indicating the RNG hardware block was either unpowered, clock-gated, or the MMIO mapping was stale/invalid on the shikra-iqs-evk platform. This is NOT related to the fastrpc PR patch (PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962), which only modifies DSP PD notification handling in drivers/misc/fastrpc.c and has no interaction with the RNG subsystem.
  3. Possible fix: This is a pre-existing platform/hardware issue, not a PR-introduced regression. The PR should NOT be blocked by this failure. Recommended actions: (1) Mark this test as a known issue for shikra-iqs-evk until the RNG hardware enablement is fixed in the device tree or firmware; (2) Verify the qcom,prng device node in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts has correct reg/clocks/power-domains properties and that the RNG block is properly enabled in the SoC power/clock topology; (3) Check if the RNG driver probe succeeded earlier in dmesg — if probe failed silently, the /dev/hwrng device may be present but backed by non-functional hardware.
  4. Detail analysis attachment: failed_case_job207591_8_detailed.md
  Case 9: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: ** The qcom_rng driver attempted to read from a hardware register (MMIO address 0xffff800080175004) during the qcom_hwrng test, but the hardware did not respond, triggering a synchronous external abort. This indicates the RNG hardware block was not accessible (likely unpowered, unclocked, or in reset) when the driver attempted to read entropy data.
  3. Possible fix: This is a pre-existing kernel issue unrelated to PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which modifies fastrpc). The qcom_rng driver needs runtime PM or clock/power dependency fixes to ensure the hardware is accessible before register reads. Short-term: skip the qcom_hwrng test on shikra-iqs-evk until the driver is fixed. Long-term: add proper power/clock management to qcom_rng probe and runtime paths, or verify DT clock/power-domain bindings for the RNG node on shikra.
  4. Detail analysis attachment: failed_case_job207591_9_detailed.md
Job 207592 | SoC qcs6490-rb3gen2

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207592

Failed test cases in LAVA job 207592 (SoC: qcs6490-rb3gen2).

  Case 1: ** Probe_Failure_Check — False Positive (Benign Regulatory Firmware Message)
  1. Failed case: ** Probe_Failure_Check — False Positive (Benign Regulatory Firmware Message)
  2. Root cause: ** The Probe_Failure_Check test flagged a benign regulatory.db firmware load failure (faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2) that does not indicate any kernel regression. WiFi functional tests (WiFi_OnOff, WiFi_Firmware_Driver) both passed, confirming WiFi operates correctly. The regulatory.db file is optional; cfg80211 falls back to built-in regulatory data when absent. The error source "faux_driver" suggests a test artifact, not a production driver. The PR changes (fastrpc.c) are unrelated to regulatory firmware. This is a known benign pattern on qcs6490-rb3gen2 when the rootfs does not include the wireless-regdb package.
  3. Possible fix: Update the Probe_Failure_Check test to suppress regulatory.db firmware load failures (error -2) when WiFi functional tests pass. Add a filter rule similar to the existing WiFi/BT firmware suppression rules in lava-known-benign-failures.md. No kernel or driver fix required — this is a test infrastructure tuning issue. The PR should not be blocked by this false positive.
  4. Detail analysis attachment: failed_case_job207592_1_detailed.md
  Case 2: ** USBHost (Test Infrastructure / Hardware Configuration Issue)
  1. Failed case: ** USBHost (Test Infrastructure / Hardware Configuration Issue)
  2. Root cause: ** USB host functionality is not available on the qcs6490-rb3gen2 platform in the current kernel configuration. The USB controller device node exists (a600000.usb) and is registered with IOMMU, but no USB host controller driver (dwc3-qcom or xhci-plat-hcd) probe is logged, indicating either the driver is not compiled/loaded, the device tree does not enable USB in host mode (dr_mode may be "peripheral" only), or the board hardware does not support USB host mode in this configuration.
  3. Possible fix: This is a pre-existing test infrastructure issue unrelated to PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only touches fastrpc driver). Mark this test as SKIP or EXPECTED_FAIL for qcs6490-rb3gen2 until USB host support is enabled in the kernel config and device tree, or remove the test from the qcs6490-rb3gen2 test suite if the hardware does not support USB host mode.
  4. Detail analysis attachment: failed_case_job207592_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM driver initialization failed at boot because qcs6490-rb3gen2 is running under Gunyah Type-1 hypervisor in EL2, preventing KVM from claiming HYP mode — kernel log shows kvm [1]: HYP mode not available at boot time (line 3.451549s).
  3. Possible fix: This is a platform configuration issue, not a kernel regression. The qcs6490-rb3gen2 target boots with Gunyah hypervisor enabled by default, which reserves EL2 and prevents KVM from initializing. To enable KVM testing on this platform: (1) boot without Gunyah hypervisor (requires bootloader/firmware configuration change to not load Gunyah), OR (2) exclude KVM tests from the CI test suite for rb3gen2 targets that boot with Gunyah, OR (3) use a different target board that does not run a Type-1 hypervisor. The PR (fastrpc DSP notification fix) is unrelated and does not cause this failure.
  4. Detail analysis attachment: failed_case_job207592_3_detailed.md
  Case 4: ** KVM_EL2_DTB — KVM Driver Initialization Failure (HYP mode unavailable)
  1. Failed case: ** KVM_EL2_DTB — KVM Driver Initialization Failure (HYP mode unavailable)
  2. Root cause: ** The qcs6490-rb3gen2 platform firmware does not enable EL2 (Hypervisor Exception Level) for Linux. The kernel detects HYP mode not available at boot (line 2742: kvm [1]: HYP mode not available) and skips KVM device node creation, causing /dev/kvm to be absent and all KVM tests to fail.
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. To resolve: (1) Update bootloader/firmware to boot Linux at EL2 or expose EL2 via VHE, or (2) Exclude KVM tests from the CI suite for qcs6490-rb3gen2 if EL2 support is not planned for this platform.
  4. Detail analysis attachment: failed_case_job207592_4_detailed.md
  Case 5: KVM_Infra — /dev/kvm device node not created
  1. Failed case: KVM_Infra — /dev/kvm device node not created
  2. Root cause: The qcs6490-rb3gen2 platform is running under the Gunyah hypervisor in nested virtualization mode, which prevents KVM from initializing at EL2. The kernel log shows "kvm [1]: HYP mode not available" at boot, indicating KVM detected it cannot access HYP mode because the hypervisor is already running at EL2.
  3. Possible fix: This is a platform configuration issue, not a kernel regression. The KVM tests should be skipped on qcs6490-rb3gen2 when running under Gunyah hypervisor. Add a LAVA job definition filter to exclude KVM tests for this board+hypervisor combination, or update the test suite to detect and skip KVM tests when /proc/cpuinfo or device tree indicates nested virtualization is not supported.
  4. Detail analysis attachment: failed_case_job207592_5_detailed.md
  Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: KVM tests fail on qcs6490-rb3gen2 because the SoC does not support ARM EL2 (Hypervisor mode), which is required for KVM. The kernel correctly reports "HYP mode not available" during boot, and /dev/kvm is not created. This is a hardware limitation, not a kernel bug or PR-introduced regression.
  3. Possible fix: Exclude KVM tests from the test suite for qcs6490-rb3gen2 and other SoCs without EL2 support. Add a platform capability check in the LAVA job definition to skip KVM tests when the target does not support virtualization.
  4. Detail analysis attachment: failed_case_job207592_6_detailed.md
Job 207593 | SoC qcs8300-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207593

Failed test cases in LAVA job 207593 (SoC: qcs8300-ride).

  Case 1: Probe_Failure_Check (driver probe failures)
  1. Failed case: Probe_Failure_Check (driver probe failures)
  2. Root cause: Three pre-existing platform probe failures detected on qcs8300-ride: (1) cpufreq-dt driver probe failed with -EEXIST (-17) indicating another cpufreq driver already registered, (2) Aquantia AQR115C PHY probe failed with -EINVAL (-22) due to missing firmware-name DT property, (3) regulatory.db firmware load failed with -ENOENT (-2) as the file is not present in the rootfs. None are introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 which only modifies drivers/misc/fastrpc.c DSP PD notification handling.
  3. Possible fix: These are known platform configuration issues, not regressions. (1) cpufreq-dt conflict is expected when qcom-cpufreq-hw is already loaded — verify only one cpufreq driver should be enabled for qcs8300. (2) Add firmware-name property to Aquantia PHY DT node or disable the driver if PHY firmware is not required. (3) Add regulatory.db to rootfs /lib/firmware/ or disable cfg80211 regulatory database loading if not needed. Mark this test case as expected-fail for qcs8300-ride until platform DT/config is corrected, or adjust test to ignore these known benign probe failures.
  4. Detail analysis attachment: failed_case_job207593_1_detailed.md
  Case 2: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure issue — no physical USB devices connected to the qcs8300-ride board's USB host port in the LAVA lab. The xHCI host controller initialized successfully (bus 1 registered, 1 USB2 port detected), but only the root hub enumerated (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub). The test expects functional USB devices beyond the root hub.
  3. Possible fix: This is not a kernel regression introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies drivers/misc/fastrpc.c). The fix is to either: (1) connect a USB device (keyboard, mouse, flash drive) to the qcs8300-ride board's USB host port in the LAVA lab, or (2) mark this test as SKIP when no USB devices are expected to be connected, or (3) update the test to pass when the USB host controller is functional even if no devices are physically connected.
  4. Detail analysis attachment: failed_case_job207593_2_detailed.md
  Case 3: ** KVM_Driver — /dev/kvm device node unavailable
  1. Failed case: ** KVM_Driver — /dev/kvm device node unavailable
  2. Root cause: ** KVM driver did not initialize because the qcs8300-ride (Monaco) platform does not support ARM64 virtualization extensions or EL2 access is blocked by firmware/hypervisor configuration; CONFIG_KVM=y is enabled but the hardware/firmware prerequisites for KVM are not met on this SoC.
  3. Possible fix: Mark KVM tests as expected-fail or skip for qcs8300-ride platform in the LAVA test suite; alternatively, verify with Qualcomm hardware team whether qcs8300 supports virtualization and if firmware/bootloader configuration is required to enable EL2 access for KVM.
  4. Detail analysis attachment: failed_case_job207593_3_detailed.md
  Case 4: KVM_EL2_DTB — /dev/kvm device node not available
  1. Failed case: KVM_EL2_DTB — /dev/kvm device node not available
  2. Root cause: KVM driver did not initialize at boot because the QCS8300 platform is not running in a hypervisor mode that supports KVM (EL2/VHE not available or not enabled). CONFIG_KVM is enabled in the kernel config, but the KVM ARM driver requires EL2 hypervisor support to create /dev/kvm. The platform either boots at EL1 only, or a hypervisor is present but does not expose KVM capabilities to the kernel.
  3. Possible fix: This is a pre-existing platform/firmware/bootloader configuration issue unrelated to PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies drivers/misc/fastrpc.c). The fix requires one of: (1) enabling EL2/VHE support in the bootloader/firmware for QCS8300 Ride, (2) configuring the hypervisor to expose KVM capabilities if one is present, or (3) marking KVM tests as expected-to-skip on this platform until hypervisor support is enabled. No kernel code change is required.
  4. Detail analysis attachment: failed_case_job207593_4_detailed.md
  Case 5: ** KVM_Infra (also KVM_Driver, KVM_EL2_DTB — same root cause)
  1. Failed case: ** KVM_Infra (also KVM_Driver, KVM_EL2_DTB — same root cause)
  2. Root cause: ** QCS8300 Ride platform runs Gunyah hypervisor at EL2, preventing KVM initialization; /dev/kvm cannot be created because KVM requires exclusive EL2 access which is already occupied by Gunyah.
  3. Possible fix: Mark KVM tests as SKIP (not FAIL) on platforms running Gunyah hypervisor; update test suite to detect Gunyah presence (/sys/firmware/devicetree/base/gunyah or dmesg | grep -i gunyah) and skip KVM tests accordingly.
  4. Detail analysis attachment: failed_case_job207593_5_detailed.md
  Case 6: KVM Test Failures — Platform Configuration Issue
  1. Failed case: KVM Test Failures — Platform Configuration Issue
  2. Root cause: qcs8300-ride platform is running under Gunyah hypervisor (nested virtualization context) where KVM cannot initialize because the kernel is already running as a guest VM at EL1 without access to EL2 virtualization extensions required for /dev/kvm creation. CONFIG_KVM is enabled but the KVM driver cannot probe successfully in this nested environment.
  3. Possible fix: Mark KVM tests as expected-to-skip on qcs8300-ride when running under Gunyah hypervisor, or configure the LAVA job to skip KVM test suite for this platform. This is not a kernel regression — KVM cannot function in a nested virtualization environment without nested virtualization support from the host hypervisor.
  4. Detail analysis attachment: failed_case_job207593_6_detailed.md
Job 207594 | SoC monaco-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207594

Failed test cases in LAVA job 207594 (SoC: monaco-evk).

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: WiFi driver (ath11k_pci) probe failure with error -110 (timeout) on monaco-evk platform; firmware files for regulatory.db, Bluetooth (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv), and WiFi (ath11k/WCN6855/hw2.1/nfa765/amss.bin) failed to load with error -2 (ENOENT). This is a pre-existing platform/firmware packaging issue unrelated to the PR changes in drivers/misc/fastrpc.c.
  3. Possible fix: Verify firmware files are present in the rootfs at /lib/firmware/ for the expected paths; if missing, update the firmware package in the build. The ath11k_pci probe timeout (-110) suggests the WiFi hardware initialization failed after firmware load attempts, which may indicate a board-specific hardware or power sequencing issue on monaco-evk that requires investigation independent of this PR.
  4. Detail analysis attachment: failed_case_job207594_1_detailed.md
  Case 2: ** WiFi Driver Probe Failure — Missing Firmware Dependency
  1. Failed case: ** WiFi Driver Probe Failure — Missing Firmware Dependency
  2. Root cause: ** ath11k_pci driver probe fails with -ETIMEDOUT (-110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is not present in the rootfs. The MHI transport layer cannot power up the WCN6855 WiFi chip without firmware, causing the probe to time out. This is a Monaco EVK board-specific firmware packaging issue, not a regression introduced by the PR.
  3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/), or configure the driver/device-tree to use the standard firmware path ath11k/WCN6855/hw2.1/amss.bin if the board-specific variant is not required. Verify firmware packaging in the Yocto/build recipe for Monaco EVK.
  4. Detail analysis attachment: failed_case_job207594_2_detailed.md
  Case 3: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)
  1. Failed case: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)
  2. Root cause: The ath11k_pci WiFi driver probe failed with -110 (ETIMEDOUT) on monaco-evk because the MHI firmware load for WCN6855 failed with error -2 (ENOENT) — the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory. This is a pre-existing infrastructure/firmware packaging issue, not introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which modifies only drivers/misc/fastrpc.c for DSP PD notification handling).
  3. Possible fix: Add the missing WCN6855 firmware files to the monaco-evk rootfs image. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are included in /lib/firmware/ in the Yocto build recipe or firmware package for monaco-evk. This is a build/packaging fix, not a kernel code fix.
  4. Detail analysis attachment: failed_case_job207594_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test definition marked as failed due to 3 individual test case failures (Probe_Failure_Check, WiFi_Firmware_Driver, WiFi_OnOff), all caused by ath11k WiFi driver probe failure with error -110 (timeout) on monaco-evk. The ath11k_pci driver failed to load firmware "ath11k/WCN6855/hw2.1/nfa765/amss.bin" (error -2: file not found) and subsequently timed out during probe. This is a pre-existing platform/firmware issue unrelated to the PR changes (fastrpc driver modification).
  3. Possible fix: The WiFi probe failure is a known platform issue on monaco-evk where the required WiFi firmware files are missing from the rootfs. This is not introduced by PR UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification #962 (which only modifies drivers/misc/fastrpc.c). No action required for this PR - the fastrpc changes are not related to WiFi functionality. The WiFi firmware packaging issue should be tracked separately as a platform/image build problem.
  4. Detail analysis attachment: failed_case_job207594_4_detailed.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ndechesne Nicolas Dechesne (ndechesne) Awaiting requested review from ndechesne ndechesne was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@quic-kaushalk Kaushal Kumar (quic-kaushalk) Awaiting requested review from quic-kaushalk quic-kaushalk was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@aiquny aiquny Awaiting requested review from aiquny aiquny was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
1 more reviewer
@ekanshibu Ekansh Gupta (ekanshibu) ekanshibu approved these changes
Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@Jianping-Li @qlijarvis @qcomlnxci @ekanshibu